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REMARKS 

This communication is in response to the Final Office Action of March 20, 2008. 

Claims 61-70 are pending in this application. Claim 65 has been withdrawn from 
consideration. Claim 61 has been amended to more specifically point out and distinctly claim 
the subject matter of the invention. Specifically, Claim 61 has been amended to include 
executable instructions to "apply a rules-based, multi-scan normalization to the first and second 
documents to create a normalized first document and a normalized second document maintaining 
the visual formatting of the first and second documents". Dependent Claims 66 and 68 have 
been amended accordingly. Support for the amendments is found throughout the specification, 
and in particular, at page 9, line 10, to page 12, line 3. No new matter has been added. 

Claims 61-64 and 66-70 have been rejected under 35 U.S.C. § 103(a) as being 
unpatentable over Baisley, U.S. Patent No. 6,502,1 12 ("Baisley") in view of Aoyama et al., U.S. 
Patent No. 6,098,071 ("Aoyama") and further in view of Ball et al., U.S. Patent No. 6,366,933 
("Ball"). Applicant traverses the rejections. Reconsideration of these claims is respectfully 
requested. 

Applicant respectfully submits that the combination of Baisley, Aoyama, and Ball does 
not disclose the computer readable storage medium of the type called for in Claim 61. In 
particular, the proposed combination does not disclose applying "a rules-based, multi-scan 
normalization to the first and second documents to create a normalized first document and a 
normalized second document maintaining the visual formatting of the first and second 
documents". 

The Examiner has suggested that "since Applicant's specification defines 'normalization' 
as involving conversion of an HTML document into blocks, wherein each block may be treated 
as a single line (see Specification page 9 lines 1-8), Ball's teaching of a token line (in 
combination with Baisley and Aoyama) teaches a 'normalized' document". (Office Action, Page 
4). 

Applicant respectfully submits that the Examiner is incorrect in his characterization of 
Ball (in combination with Baisley and Aoyama) as teaching the claimed "normalized" document. 
The claimed "normalized" first and second documents are created by "a rules-based, multi-scan 
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normalization" (Claim 61) that maintains "the visual formatting of the first and second 
documents" (Claim 61). As described in the Specification with reference to Figure 3, the first 
and second documents are scanned multiple times "based on one or more normalization rules 
that may be stored in rules database 34". (Specification, page 8, line 21 , to page 9, line 1). 

For example, "[I]n step 42, the entire HTML document is scanned and any HTML head 
element are removed from the document. In step 44, the HTML document is scanned again and 
any references to scripts in the HTML document are removed. In step 46, the HTML document 
is scanned again and any intradocument links are removed. In step 48, the HTML document is 
scanned again and any relative URLs in the HTML document are converted into absolute URLs. 
These rules in steps 42-48 provide special handling of HTML elements which are not valid when 
removed from the context of the original page. Now, the entire HTML document is scanned 
again on a character by character basis to complete the normalization process". (Specification, 
page 9, lines 12-21). 

This muti-scan, rules-based normalization "permits those documents to be compared by a 
typical line comparison module 36 and then to display the results of the comparison while 
maintaining the formatting on the HTML documents". (Specification, page 9, lines 2-4). 
"Equivalent representations, once normalized, will appear identical when analyzed via typical 
line differencing". (Specification, page 11, lines 10-11). 

No such multi-scan, rules-based normalization is taught, suggested, or disclosed in the 
cited references, either alone, or in combination. As discussed in the previous response filed on 
June 19, 2008, Ball does not even perform any normalization of HTML documents. In Ball, 
"[A] simple lexical analysis of an HTML document creates the token sequence and converts the 
case of the markup name and associated (variable,value) pairs to upper-case; parsing is not 
required" (Ball, col. 18, lines 19-22, emphasis added.) Since no parsing is required, Ball 
therefore teaches away from performing the normalization of the present invention. 

The Examiner has identified the "token line" of Ball as teaching a "normalized" 
document. Applicant respectfully submits that the token line of Ball is not the claimed 
"normalized" document because the token line does not maintain "the visual formatting" of the 
original document. As described above, multiple scans and rules are applied to the original 
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document to guarantee that "the visual formatting" of the original document is preserved in the 
normalized document. No such scans or rules are applied to the document in Ball to generate the 
token line and "provide special handling of HTML elements which are not valid when removed 
from the context of the original page". (Specification, page 9, lines 18-19). 

Furthermore, the "token line" disclosed in Ball does not correspond to "block elements in 
each document" (Claim 61). As described in Ball, "[I]n htmldiff, a token is either a sentence- 
breaking markup or a sentence, which consists of a sentence of words and non-sentence-breaking 
markups". (Ball, col. 18, lines 15-18). A block element, in contrast, may span multiple 
sentences. For example, "each paragraph shown in Figures 4 and 5 is inside a block-level 
HTML element that is deliberately arranged on a single line". (Specification, page 13, lines 6-7). 

In short, there is no teaching, suggestion, or disclosure in Ball of a normalized document 
that preserves the visual formatting of the original document and is created by a "multi-scan, 
rules-based normalization". (Claim 61). 

There is also no teaching, suggestion, or disclosure in Baisley or Aoyama of such a 
normalization. As discussed in the previous responses filed on June 19, 2008, and on July 30, 
20007, the graph taught in Baisley and the document tree taught in Aoyama are not normalized 
documents that are "coded in the markup language" and that maintain "the visual formatting" of 
the original document. 

In summary, the combination of Ball, Baisley, and Aoyama does not disclose, teach, or 
suggest the claimed element of executable instructions to "apply a rules-based, multi-scan 
normalization to the first and second documents to create a normalized first document and a 
normalized second document maintaining the visual formatting of the first and second 
documents". The lack of disclosure, teaching, or suggestion for creating normalized documents 
with such a normalization (Claim 61) is a strong indication that doing so was not obvious at the 
time the invention was made. 
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Accordingly, in view of the foregoing amendments and remarks, it is respectfully 
submitted that the application is now in condition for allowance. The Examiner is invited to 
contact the undersigned if there are any residual issues that can be resolved through a telephone 
call. 

Respectfully submitted, 
Date: January 16, 2009 COOLEY GODWARD KRONISH LLP 

Customer No. 83282 

SAP Global c/o Coolly Godward Kronish llp 
777 6 th Street NW, Suite 1 100 
Washington, DC 20001 

Tel: (650) 843-5622 
Fax: (202) 842-7899 



By: 

William S. Galliani 
Reg. No. 33,885 
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